Any comments on this?

I'm not completely sure about the benefit here.. The whole point is to create the value in the cache if it doesn't exist, so the logic of getting/creating the key is encapsulated by simple_cache without any further checks of found/not found in the caller. Can you elaborate a bit more on how are you using it?

Thanks for the pull, by the way, and sorry it took me so long to reploy

Example usecase: I need to check cache and then do the calculation which could lead to some result with no value being cached.
E.g. some token authentication - you check if this token exists in the cache, and if it is not you do some request to remote token checking server which could give ok or {error, Reason} and if you don't receive ok that received value should not be stored in the cache.
I don't see how this could be possible to implement that easily with the current simple_cache API

Great. What about (in this particular scenario) just let the request crash with something like:

ok = do_request()

That can be done in the function that you pass as argument in the get() function. If the function crashes, nothing will be cached and the caller can trap the error and act accordingly, no double checks are involved and the operation looks "more atomic".

Makes sense?

I came to that variant when I was formulating answer to you.
That looks like an option but it has a bad smell of business logic programmed with exceptioins. I.e. if that error could lead to process crash then it'd be ok but if responding correctly to a bad token is a part of correct implementation then it's not a very good choice.

if you have to react to the error instead of letting things crash, you can do:

try
  get_and_cache_token(token_cache, 86400000, a_token, fun() ->
    case get_token() of
      ok -> ok;
      {error, Error} -> throw(Error)
    end
  end)
catch
  _:BadError -> deal_with_it(BadError)
end

Yep, that's what I call "business logic programmed with exceptioins" but that's an option of course.